The kernel of an operating system manages the hardware resources in a computer system. For example, the kernel manages the memory, processor, input/output resources, and retentive storage resources of the computer system. Debugging the code that implements the functionality of the kernel is more difficult than debugging application software since debugger tools generally rely on the services provided by the operating system. If the kernel code relied upon by the debugger tool does not function as intended, then the debugging tool may not operate as intended or report erroneous results. Thus, it may be difficult to replicate and isolate certain errors in the kernel.
Given the resources managed by the kernel and the processing needs of debugger tools, various strategies have been adopted to test operating system kernels. One debugging strategy uses a client-server arrangement to implement the debugging tool. Selected user interface capabilities of the debugging tool are implemented on a client system, and debugger control functions are implemented on the server system. The client and server components of the debugger communicate via a network.
Some LAN-based debuggers implement networking code that is separate from the networking code of the kernel. However, the size and complexity of TCP protocols makes it infeasible to maintain a dedicated program to convert between TCP and lower-level protocols used by the debugger. Thus, some debuggers are based on the Ethernet layer or the UDP protocol and lack the benefits provided by TCP, such as reliable communications from anywhere in the Internet. Other debuggers include daemons that execute on systems on the network, which are near the server system and convert between the lower-level network traffic and the TCP protocol. In yet another approach, if network access is required for traffic other than debugging, at least two networking interface cards are provided, one dedicated to debugging traffic and another dedicated to other network traffic.
Developers are sometimes confronted with the task of debugging a kernel on server hardware that lacks a second LAN interface card to support debugging. Other times, the server is connected to a network for which the requisite protocol conversion daemon has not been installed. Faced with these obstacles, developers may forego the benefits of robust debuggers and resort to print statements in the kernel code, which lacks the flexibility and capabilities of debugger tools.
A system and method that address the aforementioned problems, as well as other related problems, are therefore desirable.